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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 

Summary 


This RFC is a near-verbatim copy of a document, known as NADF-123, 
which has been produced by the North American Directory Forum (NADF). 
The NADF is a collection of organizations which offer, or plan to 
offer, public Directory services in North America, based on the CCITT 
X.500 Recommendations. As a part of its charter, the NADF must reach 
agreement as to how entries are named in the public portions of the 
North American Directory. NADF-123 is a scheme proposed for this 
purpose. The NADF is circulating NADF-123 widely, expressly for the 
purpose of gathering comments. The next meeting of the NADF is in 
mid-July, and it is important for comments to be received prior to 
the meeting, so that the scheme may receive adequate review. 
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ABSTRACT 


This is one of a series of documents produced for discussion within 
the North American Directory Forum. Distribution, with attribution, 
is unlimited. This document is being circulated for comment. The 
deadline for comments is July 1, 1991. Comments should be directed 
to the contact given on page 16. 


1. Introduction 


Computer networks form the infrastructure between the users they 
interconnect. For example, the electronic mail service offered by 
computer networks provides a means for users to collaborate towards 
some common goal. In the simplest cases, this collaboration may be 
solely for the dissemination of information. In other cases, two 
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users may work on a joint research project, using electronic mail as 
their primary means of communication. 


However, networks themselves are built on an underlying naming and 
numbering infrastructure, usually in the form of names and addresses. 
For example, some authority must exist to assign network addresses to 
ensure that numbering collisions do not occur. This is of paramount 
importance for an environment which consists of multiple service 
providers. 


2. Approach 


It should be observed that there are several different naming 
universes that can be realized in the Directory Information Tree 
(DIT). For example, geographical naming, community naming, political 
naming, organizational naming, and so on. The choice of naming 
universe largely determines the difficulty in mapping a user’s query 
into a series of Directory operations. Although it is possible to 
simultaneously support multiple naming universes with the DIT, this 
is likely to be unnatural. As such, this proposal focuses on a 
single naming universe. 


The naming universe in this proposal is based on civil authority. 
That is, it uses the existing civil naming infrastructure and 
suggests a (nearly) straight-forward mapping on the DIT. There are 
four components to the naming architecture: 


(1) civil naming and optimized civil naming, which reflects 
names assigned by civil authority; 


(2) organizational naming, which reflects names assigned 
within organizations; 


(3) ADDMD naming, which reflects names assigned to public 
providers within the Directory service; and, 


(4) application naming, which reflects names assigned to OSI 
entities. 


An important characteristic is that entries should be listed wherever 
searches for them are likely to occur. This implies that a single 
object may be listed under several entries. 


2.1. Names and User-Friendliness 


It must be emphasized that there are three distinct concepts which 
are often confused when discussing a naming scheme: 
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(1) user-friendly naming: a property of a Directory which 
allows users to easily identity objects; 


(2) user-friendly name: a technique for naming an object 
which exhibits "friendliness" according to an arbitrary 
set of user-criteria; and, 


(3) Distinguished Name: the administratively assigned name 
for an entry in the OSI Directory. 


It must be emphasized that Distinguished Names are not necessarily 
user-friendly names, and further, that user-friendly naming in the 
Directory is a property of the Directory Service, not of 
Distinguished Names. 


2.2. Choice of RDN Names 


The key aspect to appreciate for choice of RDNs is that they should 
provide a large name space to avoid collisions: the naming strategy 
must provide enough "real estate" to accommodate a large demand for 
entries. This is the primary requirement for RDNs. A secondary 
requirement is that RDNs should be meaningful (friendly to people) 
and should not impede searching. 


However, it is important to understand that this second requirement 
can be achieved by using additional (non-distinguished) attribute 
values. For example, if the RDN of an entry is 


organizationName is Performance Systems International 


then it is perfectly acceptable (and indeed desirable) to have other 
values for the organizationName attribute, e.g., 


organizationName is PSI 


The use of these abbreviated names greatly aids searching whilst 
avoiding unnecessary Distinguished Name conflicts. 


In order to appreciate the naming scheme which follows, it is 
important to understand that it leverages, wherever possible, 
existing naming infrastructure. That is, it relies heavily on non- 
OSI naming authorities which already exist. Note that inasmuch as it 
relies on existing naming authorities, there is little chance that 
any "final" national decision could obsolete it. [Footnote: Any 
naming scheme may be subject to the jurisdiction of certain national 
agencies. For example, the US State Department is concerned with any 
impact on US telecommunications treaty obligations.] (To do so would 
require a national decision that disregards existing national and 
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regional infrastructure, and establishes some entirely new and 
different national naming infrastructure.) 

3. Civil Naming 
Civil naming occurs at three levels: 


(1) the national level, which contains objects that are 
recognized throughout a country; 


(2) the regional level, which contains objects that are 
recognized throughout a state or state-equivalent; and, 


(3) the local level, which contains objects that are 
recognized within a populated place. 


3.1. Naming at the National Level 
At the national-level (at least) three kinds of names may be listed: 
(1) The States and State-Equivalents 
(2) Organizations with National Standing 


(3) ADDMD Operators 


3.1.1. The States and State-Equivalents 


For each state or state-equivalent (the District of Columbia and the 
eight outlying areas [Footnote: i.e., American Samoa, Federated 
States of Micronesia, Guam, Marshall Islands, Northern Mariana 
Islands, Palau, Puerto Rico, and Virgin Islands of the US.]), an 
instance of an 


usStateOrEquivalent 
object is used. The RDN is formed as 


localityName is <FIPS 5 name> 


localityName is California 
provides the RDN for the State of California. In addition, this 


entry would contain attributes identifying both the FIPS 5 alpha and 
numeric code for the State, e.g., 
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fipsStateNumericCode is 06 
fipsStateAlphaCode is CA 
Of course, this entry could contain many other attributes such as 
stateOrProvinceName is State of California 
3.1.2. Organizations with National Standing 
There is no authority in the United States which unambiguously 
registers the alphanumeric names of organizations with national 
standing. It is proposed that ANSI provide this registry and that 
the ANSI alphanumeric name form be used as the basis for RDNs. 
For each organization with national standing, an instance of an 
usOrganization 


object is used. The RDN is formed as 


organizationName is <ANSI alphanumeric name form> 


organizationName is Performance Systems International 


In addition, this entry would contain attributes identifying the ANSI 
Alphanumeric name form, e.g., 


ansiOrgNumericCode is 177777 

Of course, this entry would contain many other attributes such as 
organizationName is PSI 

For the National Government, an instance of an 
organization 


object is also used, and the RDN is taken from the ANSI alphanumeric 
name form registry. 


3.1.3. ADDMD Operators 
There is no authority in the United States which unambiguously 
registers the names of ADDMD operators. It is expected that the 


North American Directory Forum will coordinate with the US CCITT 
National Committee Study Group D to provide this registry. (At 
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worst, the ADDMDs can use ANSI alphanumeric name forms for their RDN 
attribute values.) 

For each ADDMD operator, an instance of a 
nadfADDMD 
object is used. The RDN is formed as 


addmdName is <NADF registered name> 


addmdName is PSINet 
3.2. Naming within a State or State-Equivalent 
At the regional level (at least) two kinds of names may be listed: 
(1) Populated Places 
(2) Organizations with Regional Standing 
3.2.1. Populated Places 


For each populated place within a state or state-equivalent, 
an instance of an 


usPlace 
object is used. The RDN is formed as 


localityName is <FIPS 55 name> 


localityName is Hartford 
provides the RDN for the Hartford entry immediately subordinate to 
the usStateOrEquivalent entry for the State of Connecticut. In 
addition, this entry would contain attributes identifying the FIPS 55 
place code, e.g., 


usPlaceCode is 37000 
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3.2.2. Organizations with Regional Standing 
An organization is said to have regional standing if it is registered 
with the "Secretary of State" or similar entity within that region, 
as an entity doing business in the region. 
For each organization with regional standing, an instance of an 
organization 


object is used. The RDN is formed as 


organizationName is <registered name of organization> 


organizationName is Network Management Associates 
might provide the RDN for a business entity registered with the State 
of California. In this case, the entry thus named would be 
immediately subordinate to the usStateOrEquivalent entry for the 
State of California. 
Note that other non-distinguished attributes, such as an ANSI numeric 
name form value, may be included in such an entry --- the 
organization object might actually be a usOrganization object. 
For the Regional Government, an instance of an 

organization 

object is also used. The RDN is formed as: 
organizationName is Government 
3.3. Naming within a Populated Place 

At the local level (at least) three kinds of names may be listed: 
(1) Persons 


(2) Organizations with Local Standing 


(3) MHS Distribution Lists 
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3.3.1. Naming of Persons 
Within a populated place, there is no centralized naming entity which 
registers residential persons. It is proposed that entries for 
persons be immediately subordinate to the usPlace object which most 
accurately reflects their place of residence. 


For each person (wishing to have an entry in the Directory), an 
instance of a residentialperson 


residentialPerson 
object is used. The RDN is usually multi-valued, formed with 

commonName is <person’s full name> 
and some other attribute, such as postalCode, streetAddress, etc. 
However, because streetAddress is often considered private 
information, based on agreement with the entity managing the DMD and 
the listed person, some other, distinguishing attribute may be used, 
including a "serial number" (having no other purpose). It should be 
noted however that this is non-helpful in regards to searching, 
unless other attribute values containing meaningful information are 
added to the entry and made available for public access. 

3.3.2. Organizations with Local Standing 

An organization is said to have local standing if it is registered 
with the County or City Clerk or similar entity within that locality 
as an entity "doing business" in that place. 
For each organization with local standing, an instance of an 

organization 


object is used. The RDN is formed as 


organizationName is <registered name of organization> 


organizationName is The Tied House 


might provide the RDN for a business entity registered with the City 


of Mountain View. In this case, the entry thus named would be 
immediately subordinate to the usPlace entry for the City of Mountain 
View. 
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Note that other non-distinguished attributes, such as an ANSI numeric 
name form value, may be included in an entry. (That is, the 
organization object might actually be a usOrganization object.) 
For the Local Government, if any, an instance of an 
organization 
object is also used. The RDN is formed as: 
organizationName is Government 
3.4. Naming of MHS Distribution Lists 
Naming of MHS distribution lists remains with the scoping DMD. 


4. Optimized Civil Naming 


The structure of the civil component of the architecture can be 
concisely described as: 


Level Element objectClass Superior RDN 
root 0 
intl I country 0 countryName 
natl 2 usStateOrEquivalent 1 localityName 
3 usOganization 1 organizationName 
4 nadfADDMD 1 addmdName 
reg 5 usPlace 2 localityName 
6 organization 2 organizationName 
local 7 residentialPerson 5 commonName, 
other 
8 organization 5 organizationName 
9 mhsDistributionList 9 commonName 


Consider how an interrogation algorithm might locate a residential 


person, 


(1) 


(2) 


NADF 


given: 


a string denoting the person’s real-world name; 


a string denoting the real-world name of the populated 


place in which the person lives; 


and, 
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(3) the Distinguished Name of the state or state-equivalent. 


A straight-forward approach is to initiate a single-level search to 
locate the desired populated place. The search results in zero or 
more Distinguished Names being returned which correspond to the 
string provided by the user. Then, for each populated place, a 
subtree search might be initiated to locate the desired residential 
person. If the number of populated places returned by the first 
search is large, then this strategy is inefficient. 


A better approach would be to initiate a single search, with a filter 
combining the strings for both the person’s real-world name and the 
place’s real-world name. Unfortunately, such a search would have to 
involve the whole-subtree anchored at the Distinguished Name for the 
state or state-equivalent, which would be inefficient. 


As such, it may be desirable to optimize the civil naming component 
by listing some entries at a higher level. This is accomplished by 
using a multi-valued RDN formed by combining the RDNs of the entry 
and its superior. 


There are three cases in civil naming: 


(1) listing an organization with regional standing at the 
national level; 


(2) listing an organization with local standing at the 
regional level; and, 


(3) listing a person with local standing at the regional 
level. 


Hence, under the optimized civil naming component, a single-level 
search, anchored at the Distinguished Name for the state or state- 
equivalent, could be used. Further, the implementation of a DSA 
supporting this optimization would highly-index the attributes used 
for searching, in order to achieve high-performance. 


In order to clearly indicate that optimized civil naming is in 
effect, a new attribute type, nadfSearchGuide, is introduced. An 
attribute value of this type is placed in an entry to indicate which 
optimizations are in effect. Using the residential example above, 
the entry for the state or state-equivalent would contain an 
nadfSearchGuide value indicating that when searching for entries of 
type residentialPerson, a single-level search should be performed 
with a filter containing the logical-and of two terms, one involving 
the commonName attribute, and the other involving the localityName 
attribute. The nadfSearchGuide is a refinement of the X.500 
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searchGuide in that it indicates the depth of the search which should 
be performed, and always contains an indication of the object class 
for which the optimization exists. 


Finally, note that for naming within organizations, this technique 
might also be used. 


4.1. Naming at the National Level 
4.1.1. Organizations with Regional Standing 


An organization with standing within a state or state-equivalent may 
be listed directly under c=US. 


For an organization with regional standing, an instance of an 
organization 
object is used. The RDN is multi-valued, formed as 


organizationName is <registered name of organization> 
localityName is <FIPS 5 name> 


organizationName is Network Management Associates 
localityName is California 


It must be emphasized that uniqueness within the RDN comes from using 

the a regional localityName (state or state-Equivalent) in 

association with the correspondent organizationName in that region. 
4.2. Naming within a State or State-Equivalent 


4.2.1. Organizations with Local Standing 


An organization with standing within a populated place may be listed 
directly under its state or state-equivalent. 


For an organization with local standing, an instance of an 
organization 
object is used. The RDN is multi-valued, formed as 


organizationName is <registered name of organization> 
localityName is <FIPS 55 name> 
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organizationName is The Tied House 
localityName is City of Mountain View 


It must be emphasized that uniqueness within the RDN comes from using 
the a local localityName (populated place) in association with the 
correspondent organizationName in that place. 
4.2.2. Persons 

An person may be listed directly under its state or state-equivalent. 
For such a person, an instance of a 

residentialPerson 
object is used. The RDN is multi-valued, formed by taking the RDN of 
the person and adding the RDN of the populated place containing the 
person. 

commonName is the Marshall T. Rose 

postalCode is 94043-2112 


localityName is City of Mountain View 


Note that for optimization to occur, the RDN of the person must not 
contain a localityName attribute value. 


5. Organizational Naming 


The internal structure of each usOrganization or organization object 
is a matter for that organization to establish. 


It is strongly recommended that organizationalUnit objects be used 
for structuring. (If an organization uses a locality-based 
organizational hierarchy, this information can still be represented 
using the 
organizationalUnit 
object.) 


6. ADDMD Naming 


The internal structure of each nadfADDMD object is a matter for that 
service-provider to establish. 
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7. Application Naming 
There are (at least) four kinds of OSI entities which may be listed: 
(1) Application Processes and Entities 
(2) MHS Distribution Lists 
(3) EDI Users 
(4) Devices 
7.1. Naming of Application Processes and Entities 
Naming of OSI application processes and entities remains with the 
scoping DMD. However, in order to foster interoperability, two 
requirements are made: first, application entity objects must be 
immediately subordinate to application process objects; and, second, 
application entities are represented by the nadfApplicationEntity 
object, which is identical to the applicationEntity object except 
that the presence of an attribute value of 
supportedApplicationContext is mandatory. 
7.2. Naming of MHS Distribution Lists 
Naming of MHS distribution lists remains with the scoping DMD. 
7.3. Naming of EDI Users 
Naming of EDI users remains with the scoping DMD. 
7.4. Naming of Devices 
Naming of OSI devices remains with the scoping DMD. 


8. Usage Examples 


Consider the following examples, expressed in a concise format (read 
left-to-right): 


Federal Government: 


{ c=US, o=Government } 


The State of California: 


{ c=US, 1=California } 
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The District of Columbia: 


{ c=US, 1=District of Columbia } 


An organization with national standing: 


{ c=US, o=Performance Systems International } 


An ADDMD: 


{ c=US, addmdName=PSINet } 


The Government of the State of California: 


{ c=US, l1=California, o=Government } 


The Government of the District of Columbia: 


{ c=US, 1=District of Columbia, o=Government } 


A city within the State of California: 

{ c=US, 1=California, 1=City of Mountain View } 
An organization licensed to operate within the State of 
California: 

{ c=US, 


1=California, 
o=Network Management Associates, Inc. } 


An optimized listing for a organization with regional 
standing: 


{ c=US, 


{ 1l=California, 
o=Network Management Associates }} 
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A city government: 
{ c=US, 
1=California, 


1=City of Mountain View, 
o=Government } 


A residential person: 
{ c=US, 
1=California, 
1=City of Mountain View, 
{ cn=Marshall T. Rose, postalCode=94043-2112 }} 
An organization licensed to operate within a city: 
{ c=US, 
1=California, 
1=City of Mountain View, 
o=The Tied House } 


An entity within the Federal Government: 


{ c=US, o=Government, ou=Department of the Air Force } 


An entity within an organization with national standing: 
{ c=US, 
o=Performance Systems International, 
ou=Marketing } 
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The NADF is soliticting comments on this naming scheme. Comments 
should be directed to: 


Postal: Dr. Marshall T. Rose 
Performance Systems International 
5201 Great American Parkway 


Suite 3106 
Santa Clara, CA 95054 
US 
Telephone: +1 408 562 6222 
Fax: +1 408 562 6223 
Internet: mrose@psi.com 
X.500: rose, psi, us 


Comments should be received prior to July 1, 1991. 
Appendix A: Naming Architecture 
There are two aspects to the naming architecture: a DIT structure and 


a set of related Schema definitions. These are shown on pages 17 and 
18, respectively. 
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DIT Structure 
Level Element objectClass Superior RDN 
root 0 
intl a country 0 countryName 
natl 2 usStateOrEquivalent 1 localityName 
3 usOganization 1 organizationName 
4 nadfADDMD 1 addmdName 
reg 5 usPlace 2 localityName 
6 organization 2 organizationName 
local 7 residentialPerson 5 commonName, 
other 
8 organization 5 organizationName 
9 mhsDistributionList 5 commonName 
opt 6* organization 1 organizationName, 
localityName 
R residentialPerson 2 commonName, 
other, 
localityName 
8* organization 2 organizationName, 
localityName 
org 10** organizationalUnit 3,6,8,10,11 orgUnitName 
TIA locality 3,6,8,10,11 localityName 
ak 2k organizationalRole 3,6,8,10,11 commonName 
ABS eats organizationalPerson 3,6,8,10,11 commonName 
appl 14 applicationProcess 3,6,8,10,11 commonName 
15 nadfApplicationEntity 14 commonName 
16 mhsDistributionList 3,6,8,10,11 commonName 
17 ediUser 3,6,8,10,11 ediName 
18 device 3,6,8,10,11 commonName 


* = These are the optimized form of the corresponding element in the 
civil component. 


** = This scheme makes no requirements on the DIT structure within an 


NADF 
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organization. The organizational structure shown here is only for 
exposition. For example, MHS objects are not listed beneath the 
organizational level, though they are likely to occur within an 
organization. 


Schema Definitions 


NADF-SCHEMA { joint-iso-ccitt mhs(6) group(6) al-grimstad(5) 
nadf (1) schema(1) } 


DEFINITIONS ::= BEGIN 


IMPORTS 
OBJECT-CLASS, ATTRIBUTE 
FROM InformationFramework 
{ joint-iso-ccitt ds(5) module (1) 
informationFramework(1) } 
caselIgnoreStringSyntax, Criteria 
FROM SelectedAttributeTypes 
{ joint-iso-ccitt ds(5) module (1) 
selectedAttributeTypes(5) } 
locality, organization, applicationEntity, top 
FROM SelectedObjectClasses 
{ joint-iso-ccitt ds(5) module (1) 
selectedObjectClasses(6) } 


nadf OBJECT IDENTIFIER ::= { joint-iso-ccitt mhs(6) group (6) 
al-grimstad(5) 1 } 


nadfModule OBJECT IDENTIFIER ::= { nadf 1 } 
nadfAttributeType OBJECT IDENTIFIER ::= { nadf 4 } 
nadfObjectClass OBJECT IDENTIFIER ::= { nadf 6 } 


-—- object classes 


usStateOrEquivalent OBJECT-CLASS 

-—- localityName is used for RDN 

-- values come from US FIPS PUB 5 

SUBCLASS OF locality 

MUST CONTAIN { fipsStateNumericCode, 
fipsStateAlphaCode, 
stateOrProvinceName } 

MAY CONTAIN { nadfSearchGuide } 

::= { nadfObjectClass 1 } 
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usPlace OBJECT-CLASS 
-—- localityName is used for RDN 
-- values come from US FIPS PUB 55 
SUBCLASS OF locality 
MUST CONTAIN { fipsPlaceNumericCode, 
localityName } 
MAY CONTAIN { nadfSearchGuide } 
:= { nadfObjectClass 2 } 


usCounty OBJECT-CLASS 
SUBCLASS OF usPlace 
MUST CONTAIN { fipsCountyNumericCode } 
::= { nadfObjectClass 3 } 


usOrganization OBJECT-CLASS 
—- organizationName is used for RDN 
-- values come from ANSI Alphanumeric Registry 
SUBCLASS OF organization 
MUST CONTAIN { ansiOrgNumericCode } 
MAY CONTAIN { nadfSearchGuide } 
::= { nadfObjectClass 4 } 


nadfApplicationEntity OBJECT-CLASS 
SUBCLASS OF applicationEntity 
MUST CONTAIN { supportedApplicationContext } 
::= { nadfObjectClass 5 } 


nadfADDMD OBJECT-CLASS 
-—- addmdName is used for RDN 
—- values come from NADF Registry (thd) 
SUBCLASS OF top 
MUST CONTAIN { addmdName } 
MAY CONTAIN { nadfSearchGuide } 
::= { nadfObjectClass 6 } 


-- auxiliary classes 


nadfObject OBJECT-CLASS 


SUBCLASS OF top 
MAY CONTAIN { supplementaryInformation } 


::= { nadfObjectClass 7 } 


NADF [Page 19] 


RFC 1218 


NADF 


A Naming Scheme for c=US April 1991 


—- attribute types 
fipsStateNumericCode ATTRIBUTE 


-—- semantics and values defined in US FIPS PUB 5 
WITH ATTRIBUTE-SYNTAX 
-- leading zero is significant 
NumericString (SIZE (2)) 
MATCHES FOR EQUALITY 
::= { nadfAttributeType 1 } 


fipsStateAlphaCode ATTRIBUTE 
-—- semantics and values defined in US FIPS PUB 5 
WITH ATTRIBUTE-SYNTAX 
PrintableString (SIZE (2)) 
MATCHES FOR EQUALITY -- case-insensitive 
::= { nadfAttributeType 2 } 


fipsCountyNumericCode ATTRIBUTE 
-—- semantics and values defined in US FIPS PUB 6 
WITH ATTRIBUTE-SYNTAX 
-- leading zeros are significant 
NumericString (SIZE (3)) 
MATCHES FOR EQUALITY 
::= { nadfAttributeType 3 } 


fipsPlaceNumericCode ATTRIBUTE 
-- semantics and values defined in US FIPS PUB 55 
WITH ATTRIBUTE-SYNTAX 
-- leading zeros are significant 
NumericString (SIZE (5)) 
MATCHES FOR EQUALITY 
::= { nadfAttributeType 4 } 


ansiOrgNumericCode ATTRIBUTE 
-- semantics and values defined in ANSI registry 
WITH ATTRIBUTE-SYNTAX 
INTEGER 
MATCHES FOR EQUALITY 
::= { nadfAttributeType 5 } 


addmdName ATTRIBUTE 
-- semantics and values defined in NADF registry 
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax 
:= { nadfAttributeType 6 } 
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nadfSearchGuide ATTRIBUTE 
WITH ATTRIBUTE-SYNTAX NadfGuide 
::= { nadfAttributeType 7 } 


NadfGuide ::= 
SET { 
objectClass [0] 
OBJECT-CLASS, 
criteria[1] 
Criteria, 
subset [2] 
INTEGER { 
baseObject (0), oneLevel(1), wholeSubtree (2) 
} DEFAULT oneLevel 
} 


supplementaryInformation ATTRIBUTE 
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..76)) 
::= { nadfAttributeType 8 } 


END 
Appendix B: Revision History of this Scheme 


The first version of this scheme (NADF-71) was contributed to the 
North American Directory Forum at its November 27--30, 1990 meeting. 
The (mis)features were: 


(1) Because of the lack of confidence in ANSI registration 
procedures, it was proposed that the US trademarks be 
used as the basis for RDNs of organizations with 
national-standing. 


This proved unworkable since the same trademark may be 
issued to different organizations in different 
industries. 


(2) There was no pre-existing registry used for populated 
places. 


This proved unworkable since the effort to define a new 
registry is problematic. 


The second version of this scheme was contributed to the ANSI 
Registration Authority Committee at its January 30, 1991 meeting, and 
the IETF OSI Directory Services Working Group at its February 12--13, 
1991 meeting. The (mis) features were: 
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(1) The ANSI numeric name form registry was used as the basis 
for RDNs of organizations with national standings. 


(2) The FIPS 5 state numeric code was used as the basis for 
RDNs of states and state-equivalents. 


(3) The FIPS 55 place numeric code was used as the basis for 
RDNs of populated places. 


The choice of numeric rather than alphanumeric name forms was 
unpopular, but was motivated by the desire to avoid using the ANSI 
alphanumeric name form registry, which was perceived as unstable. 


The third version of this scheme was contributed to US State 
Department Study Group D’s MHS-MD subcommittee at its March 7--8 1991 
meeting. That version used alphanumeric name forms for all objects, 
under the perception that the ANSI alphanumeric name form registry 
will prove stable. If the ANSI alphanumeric name form registry 
proves unstable, then two alternatives are possible: 


(1) disallow organizations with national-standing in the US 
portion of the DIT; or, 


(2) use the ANSI numeric name form registry instead. 


Hopefully neither of these two undesirable alternatives will prove 
necessary. 


The fourth version of this scheme (NADF-103) was contributed to the 
North American Directory Forum at its March 18--22, 1990 meeting. 
This version introduced the notion of organizations with regional 
standing being listed at the national level through the use of alias 
names and multi-valued RDNs. 


The current (fifth) version of this scheme (NADF-123) generalized the 
listing concept by introducing the notion of optimized civil naming. 
Further, the document was edited to clearly note the different naming 
components and the relation between them. 
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Security Considerations 

Security issues are not discussed in this memo. 
Author’s Address 

North American Directory Forum 

c/o Theodore H. Myer 

Rapport Communication, Inc. 

3055 Q Street NW 

Washington, DC 20007 


Tel: +1 202-342-2727 
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